1. Technical Field
The present invention generally relates to data processing systems and in particular to polling in data processing (network) systems.
2. Description of the Related Art
Polling of a network host (or resource) is necessary to determine when an asynchronous job has completed. As an example, the IBM CommonStore™ application archives mail from the Lotus Domino™ and Microsoft Exchange® mail servers to an IBM Content Manager repository. In the case of Domino (similarly with Exchange), mail archiving is accomplished by creating a new document in a jobs Database with the parameters of the archive request (the Domino Universal ID of the document, the server, archive options, etc.).
The CommonStore task monitors the jobs database for new documents. When new documents are found, the CommonStore task processes the request. Processing of the request involves moving the contents of the mail document to Content Manager and then changing the status of the job document to “COMPLETE”. A client task which depends upon the completion status of this archive operation would have to continually retrieve the job document to check the state, waiting for the state to change to COMPLETE. Obviously, if the client task constantly requests a document that has not had a status change, the client task monopolizes the client CPU and creates significant load on the Domino server.
A well-known solution is to have the client task “sleep” for a certain amount of time between polling requests. “Sleep” may be defined as the interval of time between successive polling requests. However, a client task which sleeps too long between checks of the job state is unable to act as quickly as a client task with a shorter sleep interval. The client task with the shorter sleep interval may be able to provide a quicker response to the positive result (of a job “COMPLETE” status). In a worst case example, the job state changes to COMPLETE immediately after the client task checks the job state, but the client task remains unaware of the COMPLETE state until the task sleeps one more time before checking the state again. Thus, if the client task attempts to time the execution of the archive operation, and the task sleeps for one second, for example, between polling requests, the client task's timing result may be assumed to be overestimated by anywhere in the range from 0 to 1 second. When the client task sleeps for too short an interval, the client task wastes processor (CPU) time on the client and the server, similar to the above described case (of an extreme condition) of not sleeping at all.